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Abstract. Automating the constraint modelling process is one of the 
key challenges facing the constraints field, and one of the principal ob- 
stacles preventing widespread adoption of constraint solving. This paper 
focuses on the refinement-based approach to automated modelling, where 
a user specifies a problem in an abstract constraint specification language 
and it is then automatically refined into a constraint model. In particu- 
lar, we revisit the Conjure system that first appeared in prototype form 
in 2005 and present a new implementation with a much greater coverage 
of the specification language Essence. 

1 Introduction 

Automating the constraint modelling process (the modelling bottleneck) is one 
of the key challenges facing the constraints field [TB], and one of the principal 
obstacles preventing widespread adoption of constraint solving. Without help, 
it is very difficult for a novice user to formulate an effective (or even correct) 
model of a given problem. This challenge has received a considerable amount 
of attention in the literature recently, where a variety of approaches have been 
taken to automate aspects of constraint modelling, including: machine learning 
[T]; case-based reasoning [10 ; theorem proving [5]; automated transformation of 
medium- level solver- independent constraint models |17I15I20I13| ; and refinement 
of abstract constraint specifications fi^ in languages such as ESRA P] , Essence 
0, F [7] or Zinc [11]. 

The refinement-based approach is the focus of this paper. The central idea is 
to allow a user to write abstract constraint specifications that describe a prob- 
lem above the level at which modelling decisions are made. Abstract constraint 
specification languages, such as Essence or Zinc support abstract decision vari- 
ables with types such as set, multiset, function, and relation, as well as nested 
types, such as set of sets, multiset of function variables, and so on. Problems 
can typically be specified very concisely in this way, as demonstrated by the 
example in Figure [T] However, since existing constraint solvers do not support 
these abstract decision variables directly, abstract constraint specifications must 
be refined into concrete constraint models. 

The Conjure system was introduced in prototype form by Frisch et al. [3]. It 
was able to refine a fragment of Essence limited to nested set and multiset based 
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Fig. 1. The knapsack problem, given in Essence 



decision variables into models in the Essence' solver-independent modelling 
language. This work was further developed by Frisch and Martinez-Hernandez 
[H] , who looked in depth at the issues involved in channeling efficiently between 
many different representations of high-level variables. 

This paper describes a new approach to the implementation of Conjure, 
with a much greater coverage of the Essence language and fewer limitations on 
the rewrite rules such as the requirement of the IJCAI prototype to flatten an 
Essence specification before applying the rewrite rules. 

2 Background 

Essence is a language for specifying combinatorial (decision or optimisation) 
problems (for a detailed description see [Sj). It is motivated by a desire to allow 
users to write down problems without making constraint modelling decisions. To 
this end, it has a high level of abstraction, supporting decision variables whose 
types match the combinatorial objects problems typically ask us to find, such as: 
sets, multisets, functions, relations and partitions. The key advance represented 
by the language is its support for the nesting of these types, allowing decision 
variables of type set of sets, multiset of sets of functions etc. Hence, problems 
such as the Social Golfers Problem [B] , which is naturally conceived of as finding 
a set of partitions of golfers subject to some constraints, can be specified directly 
without the need to model the sets or partitions as matrices. 

Concomitant with the decision to support abstract constraint specifications 
is the requirement to transform these specifications into constraint models. To- 
day's constraint solvers typically support decision variables with atomic types, 
such as integer or Boolean, have limited support for more complex types like sets 
or multisets, and no support for nested complex types. Hence, abstract specifica- 
tions must be refined into constraint models suitable for constraint solvers. This 
is achieved by modelling abstract decision variables as constrained collections of 
variables of more primitive type. 

The Conjure system, first presented in prototype form in [J], employs a 
system of rewrite rules to refine Essence specifications into constraint models 
in Essence' [T7] , a language derived from Essence mainly by removing facilities 
for abstraction and adding facilities common to existing constraint solvers and 
toolkits. From Essence' a tool such as Tailor [17] can be used to translate the 



model into the format required for a particular constraint solver. The new version 
of Conjure presented herein operates in the same way. One could envisage an 
alternative mode of operation where the user writes abstract specifications, which 
are then refined and solved, and then the solution(s) are mapped back to the 
abstract level. This is the subject of future research. 

There are typically many constraint models for a given abstract specifica- 
tion. Conjure is intended to generate these alternatives by providing multiple 
refinement rules for each abstract type, corresponding to the various ways in 
which a decision variable of that type can be modelled. Furthermore, for each 
way of modelling the decision variables there can be multiple rules to generate 
alternative models for a constraint on those variables. Consequently CONJURE 
often generates a large set of alternative models for an input specification. At 
this stage our focus is on generating as large a set of model as possible. In future, 
we will investigate restricting this set to good models and the selection of either 
one recommended model or a portfolio of models with complementary strengths. 

The previous Conjure prototype provided alternative rules for the refine- 
ment of arbitrarily- nested sets and multisets. The new implementation presented 
in this paper extends these rules to cover relations and functions. The remainder 
of this paper describes the new implementation of Conjure, first by describ- 
ing its architecture and then turning attention to its refinement rules and its 
implementation. 

3 The Architecture of Conjure 

Conjure is a compiler-like system. Like most compilers it has a pipeline, which 
starts with parsing, validating the input, and type-checking. After these founda- 
tion phases, it prepares the input specification for rewriting, performs rewriting, 
and docs some housekeeping. The pipeline is summarised below: 

1. Parsing 

2. Validating the input 

- [all the identifiers are defined in the declarations part) 

- {properties of declarations, ex: a function cannot be declared both total 
and partial.) 

3. Type checking the input 

4. Representations phase 

5. Auto-Channelling phase 

6. Adding structural constraints 

7. Expression rewriting 

8. Fixing auxiliary and quantified variable names 

Phases 1 3 arc the foundation phases. The representations, auto-channelling, 
and adding structural constraint phases (4-6) prepare the input specification for 
the actual task of rewriting (Phase 7). Phase 8 can be viewed as housekeeping: 
it makes the output models easier to read and imderstand. Phase 7 (expression 
rewriting) is described in detail in the following sections. There follow brief 
descriptions for the three preparatory phases preceding it. 



Representation There are two fundamental decisions to be made in formu- 
lating a constraint model. The first is as to the viewpoint (the choice of 
decision variables and their domains [£,), and the second is the choice of 
constraints on those decision variables. The Conjure prototype interleaved 
these two decisions in a constraint-wise refinement process |4 . By contrast, 
the version of Conjure described herein explores all possible viewpoints 
first before constraint refinement. This phase takes an Essence specifica- 
tion and generates a set of specifications, one per possible combination of 
variable representation decisions. 

If a variable appears in more than one constraint, it is possible for that 
variable to be represented in different ways in different constraints, in case 
the most efficient way of representing a complex decision variable differs 
among the constraints it appears in. If a variable is represented in more 
than one way in a specification, channelling constraints between the two (or 
more) representations are added automatically in Phase 5. 

Auto-Channelling If we choose more than one way of representing a com- 
binatorial object within a specification, we automatically add channelling 
constraints [H] between different representations of the same variable in 
this phase to maintain consistency. 

Adding structural constraints In this phase we add all necessary structural 
constraints for every decision variable in the specification. The structural 
constraint for a representation of a decision variable makes sure the selected 
representation actually represents a valid combinatorial object with the in- 
tended properties (e.g. ensuring that the elements of a set are distinct). We 
add these constraints before rewriting because they will be added regardless 
of the rest of the specification and they only depend on the representation 
of a combinatorial object. 

4 Non-deterministic Rewriting 

We employ a term rewriting system to refine Essence specifications into the 
target language Essence'. Generally, rewrite rules can be thought of as partial 
functions, which map from a subterm to an equivalent subterm |I4| . Given a set 
of rewrite rules and a term, a rewrite system repeatedly applies the rules until 
no further rules can be applied. The term is then said to be in normal form. 

In order to produce alternative models we wish to generate not a single 
normal-form term, but all normal-form terms attainable by applying the given 
rules to the input term. Hence, we adjust the definition of a rewrite rule: instead 
of a function that maps from a subterm to an equivalent subterm, we define a 
rewrite rule to be a function that maps from a subterm to a set of subterms. 

A single rule is now sufficient to represent the whole rule database. This 
single rule is a one-to-many mapping from a subterm to the set of rewrites of 
that subterm. This representation is natural while applying the rules, but it is not 
a natural way to write them. It is, however, trivial to automate the combination 
of a set of partial functions into the single function used by the implementation. 

For example we can combine rulel, rule2 and rule3 in allRules as follows: 



Here rulel, rule2, and rule 3 are 
partial functions. However, the com- 
bined allRules is a total function, 
mapping from a subtcrm to a set of 
subterms. rulel rewrites A into B, 
rule2 rewrites A into C and rule3 
rewrites B into D. No rule matches C 
or D, so they are each mapped to a 
singleton set containing themselves. 

Henceforth, wc will present our rules as partial functions mapping from sin- 
gle subterms to single subterms. As above, these rules are then automatically 
combined into a single rule from subterms to sets of subterms. 

Fig. [2] presents the elements of a rule: the mapping denoted by the op- 
erator; the guards that the left hand side of the mapping must satisfy; and the 
declarations used to construct the right hand side of the mapping. Any expres- 
sion that matches the left hand side of the ^ symbol is replaced by the right 
hand side, if all guards are satisfied. 

In presenting rewrite rules we adopt the following convention, which is im- 
portant to remember throughout reading this paper. Whenever a rule uses a 
guard to restrict the type of a meta-variable on the left-hand-side of that 
meta-variable is only allowed to match an atomic expression or an expression 
of the form Array[ii, . . . , i„] (we employ a lifting mechanism to handle indexed 
expressions as if they were just simple atomic expressions). As an example, con- 
sider the rule in Fig. [3] Here the meta-variables a and b are each guarded to 
match only expressions of type set of r, where r is any type. For example, a 
and b can match against {1, 2, 3}, a decision variable or parameter whose type 
is set of set of int or x [i] where 2; is a decision variable of type matrix of 
set of int. However, a and b cannot match against the expression si union 
s2. 

Fig. [3] shows a rule that matches with a subseteq constraint between two 
sets of the same type. It rewrites the constraint into a universal quantification 
over the first set, which can be read as every element in set a must also be an 
element of set b. It also creates a quantified variable of type r, which is the type 
of the elements of the two sets. 

The symbols that we can match on the left-hand-side of a ^ are Essence 
expression constructors. These symbols can be either data constructors or op- 
erators on expressions. Currently implemented data constructors are bool, int, 

essence_expression equivalent_expression 

guards: properties that essence_expression must satisfy 

declarations: newly created variables and local aliases for expressions 
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Fig. 2. Anatomy of a refinement rule 



a subseteq b ~» forall i : a . i elem b 
guards: a ~ set of r, b ~ set of r 



Fig. 3. An example rewrite rule, ruleSetSubsetEq 



set, mset, function, relation, tuple. Some of the available operators are the 
following: abs, +, -, *, /, 7, =, !=, <, >, <=, >=, not, /\, \/, =>, <=>, card, elem, 
union, intersect, subset, subseteq, supset, supseteq, max, min, forall, 
exists, sum, matrix indexing ([]), tuple indexing (<>), function application, 
function inverse application, relation projection. 

It is useful to view our rules as operating upon an Abstract Syntax Tree (AST) 
representation of an Essence specification. In the AST, every node represents a 
term in the specification and is also labelled with that term's type. The rewriting 
system works by traversing the AST and attempting to apply the rules in the 
database at every node. A rule is allowed to modify the subtree rooted at the 
current node, and, for contextual information, is allowed to access (but not to 
modify) the remainder of the AST via the parent of the current node. If a rule 
matches the current node, the whole subtree is replaced with the equivalent 
subtree the rule suggests. 



4.1 Example Rules 

In this section we will present a number of example rules relating to the re- 
finement of set variables. These will demonstrate rules showing how expressions 
involving sets are rewritten and refined. 

We first present a series of rules that demonstrate how expressions involving 
sets can be rewritten into expressions involving simpler operators. 

a = b ~> a subseteq b /\ b subseteq a 
guards: a ~ set of r, b ~ set of r 

ruleSetEq: shows a rule that matches with an equality constraint between two 
sets. It rewrites the equality into a conjunction of mutual subseteq's between 
the two sets. The guards ensure it only applies to sets. 

e elem s exists i : s . i = e 
guards: e ~ t, s ~ set of r 

ruleSetElem: shows a rule that matches with an elem constraint and rewrites 

it into an existential quantification over the set. 

forall i : (a union b) . k ~> forall i : a . k /\ forall i : b . k 

exists i : (a union b) . k exists i : a . k \/ exists i : b . k 

forall i : (a intersect b) . k forall i : a ( i elem b => k ) 

forall i : (a intersect b) . k forall i : b ( i elem a => k ) 

exists i : (a intersect b) . k 'n-* exists i : a ( i elem b /\ k ) 

exists i : (a intersect b) . k exists i : b ( i elem a /\ k ) 
guards: a ~ set of r, b ~ set of r 



ruleSetQuan: shows a series of rules that handle quantification expressions 
on some set expressions. These simple transformations save us from creating 
intermediate set variables. 

The following series of rules show how, once constraints are reduced into a 
simpler set of operators, set variables are refined into lower-level types. Conjure 
supports refining more complex expressions directly into constraints on lower- 
level types, but we have found this method of refinement reduces our rule set, 
without reducing the set of models we can generate. 

quan i : s . k ~» quan i : r . kk 

guards: s ~ set of r, size(s) ~ bound, refinement (s) ~ explicit 

quan ~ {forall , exists , sum} 
declarations: m = matrix indexed by [r] of r 
r = intCl. .size(n)) 
kk = replace (i -> m[i]) k 

ruleRef ineSetQuan (set size bound, explicit representation): 
shows one of the core rewrite rules for handling set refinements. This rule is not 
only a simple reformulation of an expression, but it also refines the set into an 

explicit representation, using a matrix, refinement is a function that returns 
the representation of its parameter. The size function, which returns the size 
of its parameter is used here to check if the set is of a fixed size. 

forall i : s . k forall i : r . kk 

guards: s ~ set of t, size(s) ~ not boimd, maxsize(s) ~ bound 

refinement (s) ~ explicit 
declarations: m = matrix indexed by [r] of tuple<T,bool> 
r = int (1 . .maxsize(n) ) 

kk = (m[i]<l> = true) => replace (i -> m[i]<0>) k 
exists i : s . k ~> exists i : r . kk 

guards: s ~ set of t, size(s) ~ not bound, maxsize(s) ~ bound 

refinement (s) ~ explicit 
declarations: m = matrix indexed by [r] of tuple<T,bool> 
r = int (1 . .maxsize(n) ) 

kk = (m[i]<l> = true) A replace (i -> m[i]<0>) k 
sum i : s . k sum i : r . kk 

guards: s ~ set of tau, size(s) ~ not boimd, maxsize(s) ~ bound 

refinement (s) ~ explicit 
declarations: m = matrix indexed by [r] of tuple<T,bool> 
r = int (1 . .maxsize(n) ) 

kk = m[i]<l> * replace (i -> m[i]<0>) k 

ruleRef ineSetQuan (set size not bound, explicit representation): 
shows some extensions to the rule ruleRef ineSetQuan. These rules handle cases 

where there is a quantified expression over a set whose size is not known in ad- 
vance. An explicit representation of a set with unknown size requires introducing 
a matrix of tuples, where in each tuple the first component is in the set if the 
second component is true. For this representation we need different rules for each 
quantifier, maxsize is similar function to size. 



forall i : s . k forall i : r . kk 

guards: s ~ set of int, refinement (s) ~ occurrence 
declarations: m = matrix indexed by [dom] of bool 

dom = domain(tau(s) ) 

kk = (m[i] = true) => k 
exists i : s . k exists i : r . kk 

guards: s ~ set of int, refinement (s) ~ occurrence 
declarations: m = matrix indexed by [dom] of bool 

dom = domain(tau(s) ) 

kk = (m[i] = true) /\ k 
sum i : s . k sum i : r . kk 

guards: s ~ set of int, r ef inement ( s ) ~ occurrence 
declarations: m = matrix indexed by [dom] of bool 

dom = domain(tau(s) ) 

kk = (m[i] = true) * k 

ruleRef ineSetQuan (occurrence representation) : shows the final part of 
ruleRef ineSetQuan. These rules handle cases where the set is to be represented 
in occurrence representation, where a ith element of a matrix is true if i is in 
the set. domain is a function which returns the domain of its parameter, tau is 
a function which returns the type of element a container type contains. 

5 Matching Expressions not Constraints 

The prototype implementation discussed in W operated by matching against 
and rewriting complete constraints after flattening all expressions by introduc- 
ing auxiliary variables and further constraints. However, such an approach has a 
number of drawbacks. It may not be scalable in general as we may possibly have 
a huge number of constraint types that look very similar but slightly different 
(such as: x subseteq (a union b) and x supseteq (a union b)). Further- 
more, a large number of rewrite rules may be needed, one for each constraint 
type. Finally, the flattening process may introduce a large number of unneces- 
sary auxiliary variables and changes the structure of our constraints for which 
we may have better rewrite rules that exploit that structure. 

In this paper, we overcome these drawbacks by allowing our rules to match 
and rewrite expressions within a constraint rather than (necessarily) the whole 
constraint. This allows us to accomplish three things. First, we can refine a 
greater proportion of the Essence language using fewer rules. Second, un- 
like the prototype, we no longer need to flatten a specification prior to refine- 
ment avoiding introducing unnecessary auxiliary variables. Finally, we may have 
optimised rewrite rules for specific structured constraints. For instance, con- 
sider the constraint (a union b) subseteq c , if we flatten it, we would have 
X subseteq c /\ x = a union b which introduces an auxiliary variable and 
requires refining unnecessarily a set equality constraint. In our approach, in ad- 
dition to this refinement, we may rewrite this into a conjunction of two subseteq 
constraints, namely a subseteq c /\ b subseteq c, by having a dedicated 
rewrite rule which reasons about the structure of this constraint type. 



There is a subtle problem arising when we match an expression fragment 
and rewrite it to an equivalent expression fragment. The rewrite might introduce 
extra constraints and auxiliary variables. 

For instance, consider the following Essence specification: 

given lb,ut),n,in,k : int 

find t : set (size n) of int(lb..ub) 

find A : set (size n) set (size m) of int(lb..ub) 

such that 

forall s : A . (max(s) - max(t) = k) => (k elem s) 

The rewrite rule for the set max operator (max(s)) needs to introduce an 
auxiliary variable, say max_s, along with constraints that enforce that max_s is 
the maximum element in set s. We refer to these extra constraints as helper 
constraints. 

We equip our rewrite rules with an extra operator "@" which attaches a 
"bubble" to any expression containing the helper constraints. For example, our 
rewrite rule for the set max operator is as follows: 

max(s) max_s ® bubble 
guards: s ~ set of int 
declarations: majc_s = int 

bubble = (meix_s elem s) /\ (forall i : s . i >= max_s) 

If we apply our rule of the above example which contains two set max oper- 
ator, we end up with the following resulting expression: 

forall s: A . ( (max_s@bubble_s) - majc(t) = k) => (k elem s) 

forall s: A . ((max_s@bubble_s) - (max_t@bubble_t) = k) => (k elem s) 

As we can see, the intermediate expression is not a valid one yet. In fact, we 
need to move the bubbles to their correct positions. To achieve this, we introduce 
a rule which we call "ruleBubbleUp" which moves the bubbles one level up 
each time. This rule does not apply to universally or existentially quantified 
expressions. We will show later how we handle these cases. 

For each applicable expression exp, the ruleBubbleUp rule goes through each 
child of that expression and if that child has a bubble attached to it, it moves the 
bubble one level up and attaches it to expression exp. If there is more than one 
child with a bubble, we attach them in the form of a conjunction to expression 
exp. 

Without loss of generality and for the sake of simplicity, we give the definition 
of the ruleBubbleUp assuming that the expression has only child. In our current 
system, we handle expressions with any number of children. 

exp exp' b 

guards: exp is not a quantified expression, child(exp) ~ (a b) 
declarations: exp' = replace (a b) in exp with a 

In our running example, these are the results of successively applying the 
ruleBubbleUp rule: 



forall s: A . ( ( (max_s-max_t) (bubble_s /\ bubble_t) )=k) => (k elem s) 
forall s: A . ( ( (max_s-max_t=k) ® (bubble_s /\ bubble_t))) => (k elem s) 
forall s: A . ( ( (max_s-max_t=k) => (k elem s)) (bubble_s /\ bubble_t)) 

After finding the right positions for the bubbles, our next step safely converts 
"0" to conjunction "/\" resulting in the following valid expression: 

forall s: A . ( ( (max_s-max_t=k) => (k elem s)) /\ bubble_s /\ bubble_t) 

Our optional last step is to resolve the scope for the bubble expressions inside 
a universally quantified expression. ruleLoopInvariant, defined below, moves 
all expressions inside a universally quantified expression that do not fall in the 
scope of their quantifier. The rule is defined as follows: 

forall i : s . k invariants /\ forall i : s . variants 
declarations: ks = splitConjuction k 

variants = filter (hasRef erenceTo i) ks 
invariants = ks \\ variants 

Given a conjunction of constraints, the splitConjuction function returns 
a list of constraints breaking the conjunctions between them and the function 
hasRef erenceTo checks whether the second expression references the first one 
or not. Thus, our final refinement is as follows: 

bubble_t /\ forall s: A . ( ( (max_s-max_t=k) => (k elem s)) /\ bubble_s) 

6 Coverage of Essence and Limitations 

The Essence language as defined in I4j contains five core type constructors: set, 
multi-set, partition, tuple, function and relation; and the simple types 
int, bool and user-defined enumerated and unnamed types. Currently our sys- 
tem has rules for handling specifications on all the type constructors, excepting 
partition. There are 22 operators on these type constructors defined in [J]. We 
support almost all of them. The currently missing operators are mostly related 
to type-conversion and we are confident that they will be easy to implement 
without changes to our current system. Since partitions can be realised as sets 
of sets with additional constraints, we are confident that we can support these 
in the near future. 

We do not implement enumerated types and unnamed types yet. The initial 
focus of the implementation was attacking the challenging parts of Essence like 
the nested types, rather than providing a finished product. Since enumerated 
types and unnamed types can be easily transformed into int by a preprocessing 
step, we postpone the implementation of them. 

not (a) a = false 
guards : a ~ bool 

ruleNot: This rule removes negated expressions. 



alldiff(m) forall i : r . (forall j : r . (i < j) => m[i] != m[j]) 
guards: tau(m) ^ {bool,int} 
declarations: r = firstlndexQf Matrix m 

ruleComplexAlldif f : We provide a generic implementation of alldif f which 
rewrites the constraint into a cUque of not equal constraints, for use with types 
without a global alldiff constraint. 

a != b ~* not (a = b) a supset b -v^ b subset a 

a supseteq b ^ b subseteq a a subset b ~> a subseteq b /\ a != b 

guards: a ~ set of r, b ~ set of r 

ruleSetOps: Shows a selection of the rules which handle normalising set ex- 
pressions. This reduces the number of other rules which are required. 

min(s) min_s ® cons 

guards: s ~ set of int 
declarations: min_s = int 

cons = (min_s elem s) / (forall i : s . i >= min_s) 

ruleSetMin: Rewrites a min operator applied to a set variable, cons constrains 
the newly introduced variable, min_s. ruleSetMax is defined similarly. 

card(s) ~» size(s) 

guards: s ~ set of r, size(s) ~ bound 
card(s) card.s @ (card_s = sum i : dom . m[i]) 

guards: s ~ set of r, size(s) 7<i bound, maxsize(s) ~ bound 

representation(s) ~ occurrence 
declarations: card_s = int 

m = matrix indexed by [dom] of bool 
dom = domain(tau(s) ) 
card(s) card.s (card_s = sum i : dom . m[i]<l>) 

guards: s ~ set of t, size(s) / bound, maxsize(s) ~ boimd 

representation(s) ~ explicit 
declarations: card_s = int 

m = matrix indexed by [r] of tuple<T,bool> 
r = int (1 . .maxsize(n) ) 

ruleSetCard: Rewrites a card operator applied to a set variable. Is optimised 
for varibles of known size, else it creates a variable to represent the cardinality 
of the operand set. There are variants for two representations of a set. 

f(i) m[i] 

guards: f ~ function ti -> T2, i ~ ri 

representationCf ) ~ FunclD 
declarations: m = matrix indexed by [dom(ri)] of T2 
f(i) sum j : r . j X m[i,j] 

guards : f ~ function n -> r2 , i ~ ri 

representationCf ) --^ Func2D 
declarations: m = matrix indexed by [domCri) ,dom(T2)] of bool 

ruleFiuicApp: Refines function application, for two different representations of 
functions 



defined(f) defn_f 

guards: f ~ function ri -> T2, isTotal(f) ~ true 
declarations: defn_f = set of n 
defined (f) defn_f @ bubbl 

guards: f ~ function ri -> T2> representation(f ) ~ Fimc2D 

isPartialCf) ~ true 
declarations: defn_f = set of ri 

m = matrix indexed by [domCn) ,dom(T2)] of bool 

bubbl = forall i : domCrg) . 

((sum j : dom(ri) . m[j,i]) > 0) 
=> i elem defn_f 

ruleFuncDef ined; Refines the defined operator applied to a function variable. 
Simply returns the domain set of the function, if the function is declared to be 
total, else it creates a set variable and constraints it. 

range (f) range_f 

guards: f ^ function ti -> T2 , isSurjective(f ) ~ true 
declarations: range_f = set of T2 
range (f) range_f bubbl 

guards: f ~ function ti -> T2, representation(f ) ~ Fimc2D 

isSurjective(f ) 7^ true 
declarations : range_f = set of T2 

m = matrix indexed by [dom(ri) ,dom(T2)] of bool 

bubbl = forall i : dom(Ti) . 

((sum j : dom(r2) . m[i,j]) > ) 
=> i elem range_f 

ruleFuncRange: Refines the range operator applied to a function variable. This 
rule is similar to ruleFuncDef ined. 

m[i]<j> ~» n<j>[i] 

guards: m ~ matrix indexed by [indices] of tuple<components> 
declarations : n = tuple<comps'> 

comps' = V c G components . 

matrix indexed by [indices] of typeof (c) 

ruleMatrixOf Tuples: Essence supports matrices of tuples, however the target 
language does not. This rule rewrites a matrix of tuples into a tuple of matrices, 
preserving the matrix indexing and the tuple indexing. 

t<i> ^ tt 

guards: t ~ tuple<components> , i ~ integer expression 

length (components) >= i 
declarations: tt = typeof (components [i] ) 

ruleTupleOut: Rewrites an indexed tuple into a separate decision variable. 

a = b ~> forall i : r . a<i> = b<i> 

guards: a ~ tuple<componentsi> , b ~ tuple<componentS2> 

length (component si) = length(componentS2) 
declarations: r = int (0 . . length(componentsi)-l) 



ruleTupleEq: Rewrites tuple equality as equalities on the members of the tuple. 



r<is> is elem s 

guards: r ~ relation of componentsi , is ~ tuple<componentS2> 
length(componentsi) = length(componentS2) 
is contains no underscores 
declarations: s = set of tuple<componentsi> 

ruleReElem: Relation membership, representing the relation as a set of tuples. 

r<is> k<js> bubbl 

guards: r ~ relation of component Si , is ~ tuple<componentS2> 
length(componentsi) = length(componentS2) 
is contains at least one underscore 
declarations: js = underscoredlndices (is) 
k = relation of js 
bubbl = forall i : r . 

(notUnderscoredlndices (is) match with i) => 
(underscoredlndices (i) elem k) 

ruleRelnPro j : Rewrites the relation projection expressions. In a relation pro- 
jection expression, at least one of the tuple indices (is) should be left unspecified. 
This operator creates a new relation containing only those components of the 
actual relation which are left unspecified. 

The only part of Essence where we do not yet support full nesting is function 
variables that map from arbitrarily nested combinatorial objects to any type. 
We support only function variables that map from sets of integers to arbitrarily 
nested types. This is an important area of future work. 

find f : function (partial) int(lb..ub) -> r 

find g : function (partial) set (maxsize n) of int(lb..ub) -> r 

For example, we can refine f to either a 1-diniensional matrix of decision 
variables of type r, or a 2-dimensional matrix of boolean decision variables, 
depending on the actual type of r. However we cannot refine g to a matrix in 
the same way because we cannot index a matrix with complex types. 

The power of our system directly depends on the quality of our rules database. 
So far we have concentrated on achieving coverage of the Essence language, 
rather than producing good models. A further future goal is to increase both the 
quantity and breadth of our rules in order to generate the widest possible set of 
models from a specification, in preparation for then selecting the best model or 
models from the set of models we produce. 

7 Implementation 

Essence, like Zinc, is a domain-specific language (DSL) for writing abstract con- 
straint specifications. Similarly, languages such as EaCL[13 , ESRA^Sj, OPL|20j. 
Essence' [17] and MiniZinc[15] are DSLs for writing constraint models. This is 



in contrast with constraint solvers such as Hog Solver jSj and Gecode[T9], which 
are implemented as a library in a programming language such as C++. 

There are two standard methods for implementing DSLs. The first is to write 
a full parser and type checker for the language and map the language to an 
internal data structure that can be processed and executed. A second, simpler 
method is by extending an existing programming language. The DSL language 
is then called an embedded-DSL (EDSL). 

We choose a hybrid approach. We implement the language as an EDSL to 
Haskell to leverage its power, yet we still implement a complete parser and a type 
checker that can read conventional Essence specifications in. This may sound 
like duplicating some work, however, we make use of the EDSL while writing 
our rewrite rules. Using the EDSL for rewrite rules saves us a great deal of effort 
which would otherwise mean re-implementing features of the host language. 

Some languages, like Haskell, are particularly suited to this task, and can be 
used to implement concise EDSLs that are easy to use. Haskell is a statically 
typed higher-order pure functional programming language. It provides a module 
system, an advanced type system with type classes and polymorphic types. It is 
particularly powerful in manipulating data structures using its powerful pattern 
matching infrastructure. These features make it a natural candidate for hosting 
EDSLs. There are EDSLs in Haskell for many fields including but not limited to 
3D animations, image synthesis and production, and geometric region analysis. 
The hmatrix-gplk package provides an EDSL for Linear Programming, as 
well as a solver. 

Rhiger ^TS] provides further examples of EDSLs in Haskell, and describes the 
common techniques used to design them. 

Building on top of Haskell gives us the ability to leverage Haskell's rich 
type system and grow from existing types and operations. As discussed in [5], 
Essence itself is specified as a sequence of abstract lexemes. Our choice of con- 
crete lexemes was made to suit the host language. The mapping to the abstract 
lexemes of the Essence language definition is straightforward. 

8 Conclusion 

This paper has presented a new version of the Conjure automated modelling 
system, which achieves far greater coverage of the Essence language than pre- 
vious versions. There remain a small number of areas of the Essence language 
that we need to extend the system to cover, such as partition variables and func- 
tion variables that map from arbitrarily nested types. This forms an immediate 
piece of future work. Further future work includes increasing the quantity and 
breadth of our refinement rules and beginning to select among the set of models 
produced. 
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